Skip to content

Use help_formatter to consistently format help output #6931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 12, 2023

Conversation

tautschnig
Copy link
Collaborator

@tautschnig tautschnig commented Jun 15, 2022

We previously did manual line breaks that either suited the source code
line length or approximated the output line width. help_formatter, however,
was specifically built to take care of this (and just wasn't widely
used). We can then also happily have clang-format take care of source
code formatting without impacting the resulting display.

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@codecov
Copy link

codecov bot commented Jun 15, 2022

Codecov Report

Patch coverage: 18.84% and project coverage change: +0.02% 🎉

Comparison is base (4e426d3) 78.80% compared to head (722918f) 78.82%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #6931      +/-   ##
===========================================
+ Coverage    78.80%   78.82%   +0.02%     
===========================================
  Files         1698     1699       +1     
  Lines       195118   195102      -16     
===========================================
+ Hits        153757   153798      +41     
+ Misses       41361    41304      -57     
Files Changed Coverage Δ
jbmc/src/janalyzer/janalyzer_parse_options.cpp 48.43% <0.00%> (-0.16%) ⬇️
jbmc/src/java_bytecode/java_bytecode_language.h 76.47% <ø> (ø)
jbmc/src/jbmc/jbmc_parse_options.cpp 74.20% <0.00%> (-0.17%) ⬇️
jbmc/src/jdiff/jdiff_parse_options.cpp 65.62% <0.00%> (-0.70%) ⬇️
...variable-sensitivity/variable_sensitivity_domain.h 100.00% <ø> (ø)
src/ansi-c/ansi_c_language.h 75.00% <ø> (ø)
src/cprover/cprover_parse_options.cpp 56.25% <ø> (ø)
src/crangler/crangler_parse_options.cpp 52.94% <0.00%> (ø)
src/goto-analyzer/goto_analyzer_parse_options.cpp 71.84% <0.00%> (-0.43%) ⬇️
src/goto-checker/solver_factory.h 100.00% <ø> (ø)
... and 27 more

... and 4 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff but be aware of the potential revert of #6932

"(vsd-liveness)" \
\
// clang-format off
"(vsd-liveness)"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we still doing the "put a \ at the end of even the last line so that new additions are just 1-line diffs" thing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be useful, but clang-format takes them away. So I'd have to (re-)add clang-format off/on, which makes formatting more cumbersome. I'm not sure which is best, happy to take guidance!

" --vsd-liveness track variable liveness\n" \

// cland-format on
help_entry( \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel a bit weird about having the << operators for all but the first. I guess we have to out << HELP_VSD which is grammatical but ... it feels a bit weird.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to move the << over into the macros, but I don't know whether it actually makes for less weirdness. I tripped over this myself when coming up with this patch...

Copy link
Contributor

@NlightNFotis NlightNFotis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Michael.

This looks tedious, but it's a very important step to establish some uniformity and a standard around the help options.

Thanks for taking the time to sort this out.

@tautschnig
Copy link
Collaborator Author

Pinging @chris-ryder as I believe I'll strictly need your approval here.

Copy link
Collaborator

@feliperodri feliperodri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes in contracts LGTM.

"(object-bits):" \
"(gcc)"

#define HELP_CONFIG_PLATFORM \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since help_entry is a function could we instead write these as c++ functions returning std::string and avoid the multi-line macros ?

Copy link
Collaborator

@remi-delmas-3000 remi-delmas-3000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the multi-line macros that just expand chais of calls to help_entry and concatenation using << (see #define HELP_CONFIG_LIBRARY for instance) really needed or could we just use C++ functions returning std::string everywhere ?

Copy link
Collaborator

@remi-delmas-3000 remi-delmas-3000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the multi-line macros that just expand chais of calls to help_entry and concatenation using << (see #define HELP_CONFIG_LIBRARY for instance) really needed or could we just use C++ functions returning std::string everywhere ?

@tautschnig
Copy link
Collaborator Author

Are the multi-line macros that just expand chais of calls to help_entry and concatenation using << (see #define HELP_CONFIG_LIBRARY for instance) really needed or could we just use C++ functions returning std::string everywhere ?

I'll work on this.

@tautschnig tautschnig self-assigned this Jul 15, 2022
@tautschnig tautschnig mentioned this pull request Sep 19, 2022
5 tasks
@tautschnig
Copy link
Collaborator Author

I should likely rebase/rework this to use #7141.

@tautschnig tautschnig requested review from TGWDB, qinheping, a team and esteffin as code owners August 11, 2023 10:03
@tautschnig tautschnig changed the title Use help_entry to consistently format help output Use help_formatter to consistently format help output Aug 11, 2023
@tautschnig tautschnig assigned kroening and qinheping and unassigned tautschnig Aug 11, 2023
@tautschnig
Copy link
Collaborator Author

To anyone reviewing this: on this occasion, reviewing the overall diff will be more effective than doing individual commits (I'm mainly keeping the "Use help_entry" commit for sentimental reasons).

Modelled after help_entry's unit test.
We previously did manual line breaks that either suited the source code
line length or approximated the output line width. help_entry, however,
was specifically built to take care of this (and just wasn't widely
used). We can then also happily have clang-format take care of source
code formatting without impacting the resulting display.
First round of changes was done automatically:
```
sed -i 's/help_entry("\(--[^ ]*\)", "\(.*\)")/" {y\1} \\t \2\\n"/' \
  src/*/*.h src/*/*.cpp src/analyses/variable-sensitivity/*.h \
  jbmc/src/*/*.h jbmc/src/*/*.cpp
```
All further replacements were done manually.
All uses of `help_entry` have been converted to uses of
`help_formatter`.
@kroening kroening merged commit 08a466d into diffblue:develop Aug 12, 2023
@tautschnig tautschnig deleted the feature/help_entry branch August 14, 2023 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants